ASSUMPTIONS AND LINGO USED BY TCHK

    MULTIPLE ENTRY #defines

        In the interactive environment you can #define one item in
        terms of another, including spaces. If anyone knows how to do
        this with the command line version, please let me know. The
        variable type  byte  is just an unsigned char. If you use the
        command line version of TC you will have to change some of
        the header files of TCHK.

    COORDINATES

        Beginning with TCHK 2.0, unless otherwise noted, all
        functions asking for screen coordinates comply with Borland's
        format (x,y). The top left corner of the screen is (1,1).
        This is highly different from previous versions of TCHK.

    LOW MEMORY ADDRESSES

        Many functions rely on interrupts and low memory addresses
        (400:xxxx) to comply  with the IBM standard. Certain values
        (for instance, the current video page) can be found by an
        interrupt or by peeking at the value stored in low memory.
        Many of the video functions especially require these values
        to be found at the proper places. If your clone is radically
        different from the IBM standard some of these functions may
        not work properly. I didn't want to have to write a million
        small functions that are just background support for the
        functions found here (like current page number, etc.) so I
        used the #defines found in the headers (see video.h for more
        details.)

    KEYBOARD INPUT

        TCHK considers "key codes", "scan codes" and "ascii codes" as
        different animals. Via the BIOS, any key pressed returns a
        word (2-byte) value. If a 'normal' key is pressed (i.e. a
        letter, space, etc.) the low order byte contains the letter.
        When the low order byte is zero, an unusual key has been
        pressed (i.e. Alt combinations, arrows, grey +, etc.) This 2
        byte word as returned by the BIOS is called a scan code. For
        ease of use, several functions convert this "scan code" to a
        value from 0-511, called a "key code", where 0-255 are
        'normal' ascii codes, as per the IBM ASCII character set, and
        256-511 are the unusual keys. Many of the popular key codes
        are listed in KEYCODE.H. To determine a key code, if the low
        order byte is zero, take the high order byte as a number
        0-255 and add 256. If the low order byte is non-zero, take
        the low order byte as a number from 0-255. Note that although
        the regular plus key and the grey plus key (on the numeric
        keypad) return different scan codes, their key code is the
        same. So, briefly, an "ascii code" is a char (value of
        0-255), a "scan code" is a 2-byte word returned from the
        BIOS, and a "key code" is a value 0-511. "Scan codes" and
        "key codes" are both 2 bytes long (unsigned int and int,
        respectively).

    FILE NAMES

        There are several functions that refer to a DOS file name. A
        'file name' is a generic term for any possible name for a
        file (drive, path and even filename.ext are optional). A
        'filename' refers to a DOS filename.ext, no drive or path
        (sometimes referred to with 'filename.ext'). A 'filepathname'
        refers to a full file name, including drive, path and
        filename.ext (some parts may be optional.) A 'filespec' is
        similiar to a 'filename', but does not necessarily refer to a
        specific file (i.e. D:\TURBOC is actually D:\TURBOC\*.*. See
        how DIR parses filespecs for more details.)

    MDA/HERCULES VIDEO CARDS

        TCHK has not been tested on a Hercules or MDA video card
        since I do not have access to either piece of hardware,
        although the methods I used are well documented and should
        cause no problems.

    TCHK SCREEN OUTPUT

        All functions that use my direct screen access routines have
        built-in snow control. On CGA monitors, the snow was
        horrendous without it. Unless I code these routines in
        assembler, I won't be able to squeeze any more optimization
        out of these routines. Since Borland now provides acceptable
        console i/o functions, I doubt I shall bother to recode these
        in Assembler.